home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000048_owner-urn-ietf _Tue Nov 5 23:16:46 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA04135 for urn-ietf-out; Tue, 5 Nov 1996 23:16:46 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA04130 for <urn-ietf@services.bunyip.com>; Tue, 5 Nov 1996 23:16:44 -0500
  3. Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA07658  (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 23:16:40 -0500
  5. Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
  6.           id XAA28069; Tue, 5 Nov 1996 23:16:17 -0500 (EST)
  7. Message-Id: <199611060416.XAA28069@ig.cs.utk.edu>
  8. X-Mailer: exmh version 1.6.7 5/3/96
  9. X-Uri: http://www.cs.utk.edu/~moore/
  10. From: Keith Moore <moore@cs.utk.edu>
  11. To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  12. Cc: Patrik Faltstrom <paf@swip.net>, urn-ietf@bunyip.com, moore@cs.utk.edu
  13. Subject: Re: Names and Locations (was [URN] some comments) 
  14. In-Reply-To: Your message of "Tue, 05 Nov 1996 00:16:00 CST."
  15.              <199611050616.AAA21984@ncsa.uiuc.edu> 
  16. Mime-Version: 1.0
  17. Content-Type: text/plain; charset=us-ascii
  18. Date: Tue, 05 Nov 1996 23:16:17 -0500
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Keith Moore <moore@cs.utk.edu>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. > Instead, perhaps you are trying to say that the name is not tightly
  25. > bound to information associated with the resource, that the
  26. > information can change and still the name is the name of the resource.
  27. > For example, the "resolution protocol" can change.  I have no problem
  28. > with that, and never have.  But this is still not abstractly different
  29. > from what happens to a URL.  
  30.  
  31. You're right, it's not.  But the difference between URNs and URLs has
  32. almost nothing to do with how they are resolved (indeed, I hope they
  33. use the same resolution mechanisms), and a lot to do with how the
  34. names are assigned and maintained.
  35.  
  36. That is, some people think it's very useful to have a class of names
  37. for which certain properties (long-term persistence, global scope,
  38. ..., and the rest of those named in RFC 1737) hold.  Those names are
  39. called URNs.  Yes, they're a lot like URLs in how they are handled.
  40. But the whole point in having URNs as a separate name space is: if you
  41. know that a particular name is a URN, you know that the RFC 1737
  42. properties hold.  (Or if you prefer, an assertion that a name is a URN
  43. implies that the RFC 1737 properties hold.)
  44.  
  45. This is why URNs need a URN: prefix -- because a lot of the value in
  46. having a URN name space with those properties is so *humans* can
  47. recognize a URN when they see it.
  48.  
  49. Keith
  50.  
  51.